Fix for wrap-nested-params and multi-valued parameters without '[]' #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(sorry about the previous pull request... I missed a commit somehow)
I recently had to use a multiple select box on an HTML form, but didn't end the parameter name with "[]". wrap-params correctly transforms "foo=bar&foo=baz" into {"foo" ["bar" "baz"]}, but because the parameter was "foo" and not "foo[]", wrap-nested-params turned it into {"foo" "baz"}, eating all but the last value.
While this can be "fixed" by just calling the parameter "foo[]" from the beginning, it makes that a special case; you don't have to think about the brackets and whatnot when using the 'with-groups' macro in Hiccup, for instance (can't speak for other libraries like Enlive, though). In any event, wrap-nested-params was removing legitimate parameter values.
There is probably a better way to go about this; I just added another key to the middleware options map for a "multi-value-suffix" that defaults to "[]", in keeping with using the parse-nested-keys default parse function. Basically, if a multi-valued parameter is detected whose name doesn't end in the specified suffix, it gets added in the param-pairs function, making it appear "correct" to the rest of the machinery. It works, though.
Thanks,
Chris